[セッションレポート]IAM Best Practices #reinvent

[セッションレポート]IAM Best Practices #reinvent

Clock Icon2014.11.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

この記事は AWS re:Invent 2014、SEC305-JT - IAM Best Practices - Japanese Trackのレポートです。

スピーカーはAWSのAnders Samuelsson。

DSC_0022

レポート

DSC_0011

IAMとは? 機能でもありサービスである。誰が何をできるのかを制御する。 ユーザ、グループ、ロール、パーミッションのコントロール。 全てのサービスへのアクセスを一箇所で一元的に制御できる。 粒度が細かく、どこまでなにをするのかはみなさんが決められる。 Denyがdefault。許可を与えない限りは出来ない。 複数のユーザを作ることも、透過的に設定することもできる。

DSC_0012

ベストプラクティスは10個あったんだけど、11個になりました。

DSC_0013

一番最初にやること。Userを作る。CLIでもAPIでもAMCでも。 ユーザを作ったら何ができるか。権限がないので何も出来ない。

DSC_0015

まずは権限を与える。SEは読み取りのみとか。 メリットとは?ミスを減らす。 厳格化するより緩くする方が簡単にできてしまうのであとから厳しくするのは難しい。 最初にやることは何が求められているのかを確認すること。 アクセスキーが必要かどうかも考える。コンソールにアクセスする必要がない場合もある。 フルパーミットポリシー(:)は避けるべき。管理者だけでいい。 デフォルトDenyとする。何ができるのかを明示的にする。 重要なこと、パーミッションはrootには設定できない。rootは基本的に使わない。

DSC_0017

次にgroup。 管理の悪夢。それぞれのユーザに対しての権限を管理するのはとても大変。 だからグループを作る。グループに権限を与えれば管理が楽。 複数ユーザに同じレベルの権限を与えることができるから。 グループの権限を変えれば複数ユーザの権限が一緒に変わる。 どんな権限が必要なのか、どんな人たちが同じ権限になるのかを分析すること。

DSC_0018

次にアクセスコントロール。conditionsで行う。 どんな条件で誰が権限を使うのかをきめ細かく設定できる。 MFAを使ってない場合とかSSL接続の場合だけとか。 Tagがどうあるべきか、みたいな設定も可能。

DSC_0019

CloudTrailは使うべき。 API Callを全てS3バケットに保管していく。監査できる。 何かサービスを使う場合、 CloudTrailが使えることを確認したほうがいい。

DSC_0021

パスワード管理。 パスワードを細かく設定できるようになった。 社内のパスワードポリシーを確認し、それを適用できる。 文字種類、強度、再利用。 またrootにはパスワードポリシーを適用できない。

DSC_0024

security credentialsの再利用。 Credential Reportsというツールがある。 全てのユーザがいつローテションしたのかが一覧でわかる。 ローテションしていないユーザも、ローテーションを促すこともできる。 最後にサインインしたタイミングもわかるので使っていないユーザを発見することもできる。 IAM roleでは自動的にrotateされている。

DSC_0025

パスワードローテーションを有効にするIAMポリシー。 ユーザを作成するとき、password policyを強要することができる。

DSC_0026

アクセスキーをローテーションするときのIAMポリシー。 アクセスキーはアプリケーションが使うので、いくつかステップが必要。 アクセスキーの入れ替えのために、一時的に二つのアクセスキーをもたせて、 古いアクセスキーをInactiveにして、テストし、最後に古いアクセスキーをDeleteする。 あとで間違ってactiveにしないように、不要なアクセスキーはちゃんとDeleteするべき。

DSC_0028

MFA。MFAは他のクレデンシャルを補完する位置付け。 MFAのタイプを選択する。ハードウェアトークンか、バーチャルMFAか。 そしてIAMコンソールでMFAの設定をする。ユーザごとに設定が必要。 MFAはrootアカウントに必ず設定すべき。

DSC_0029

共有。データを共有する場合にクレデンシャルで許可するのではなくRoleで許可するべき。 個別にクレデンシャルを与えない。 簡単に他のサービスとリレーションすることができる。 イントラで持っているアカウントから使うこともできる。 Federationによって許可することも可能。 権限を決め、共有名を決め、ExternalIDにて3rdパーティと共有する。 絶対にクレデンシャル派共有しないこことが大事。

DSC_0031

どうやって共有しているのか?という例。

DSC_0032

ES2にIAM Roleを与える。 アクセスキーを管理する必要がない。 Roleでは勝手にキーのローテーションが行われる。

DSC_0033

今日一番重要なこと。rootは使わない。 みんながrootを共有して使っていたら全く追跡が出来ない。 rootはアクセスキーを削除して、MFAを有効にして、強いパスワードを設定。 そのまま二度と使わないくらいの運用にしてほしい。 Federateされたユーザもそう。rootは使わない。

DSC_0034

振り返り。

DSC_0035

まとめ

rootは使わないとか、MFAを使うとか、credentialを共有しないとか、基本的ではあるけれど重要な話だったと思います。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.